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(54) Serveur virtuel fournissant des services de securite 



(57) Serveur virtue! de securite permettant a un en- 
semble ^applications d'acceder a un ensemble de ser- 
vices de securite, caracterise en ce qu'il possede : 

• des moyens pour recevoir de la part des applica- 
tions logicielles des requetes de services, 

• des moyens de communication avec des serveurs 



de securite mettant en oeuvre ces services de se- 
curite, 

des moyens pour choisir au moins un serveur de 
securite destinataire pour chaque requete de servi- 
ce recue et pour lui transmettre des informations lui 
permettant de fournir le service de securite corres- 
pondant a la requdte de service. 
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Description 

[0001] La pr6sente invention est relative a un system e 
informatique necessitant la securisation des communi- 
cations entre certains des composants logiciets le com- 
posant. 

[0002] L'invention s'applique particulierement bien 
aux systemes de gestion de reseau, notamment de r6- 
seau de telecommunication. Cet exemple d'application 
sera plus particulierement developpd par la suite, mais 
('invention est toutefois susceptible de s'appliquer a 
d'autres types d'applications, par exemple aux applica- 
tions pour le commerce 6lectronique. 
[0003] De facon classique, les systemes de gestion 
de reseaux de telecommunication comportent un en- 
semble d'applications logicielles de gestion. Ces appli- 
cations peuvent dtre reparties au sein d'un systeme dis- 
tribue, et peuvent avoir besoin de communiquer entre 
el les afin d'echanger des informations. 
[0004] Un besoin peut exister de s6cu riser ces com- 
munications. En fonction de la menace que Ton craint 
ainsi que du niveau de sensibilite des informations 
transmises, differents services de securisation peuvent 
dtre mis en oeuvre, comme par exemple : 

• Identification et authentication : par cette techni- 
que, le destinataire d'un message est assure de 
I'origine de ce message. On a ainsi la garantie qu'il 
n'existe pas de messages 6mis par un tiers mal- 
veillant dans le systeme. 

• Controle d'acces : une application ne reagira aux 
commandes contenues dans les messages, qu'en 
fonction de regies definies dans une politique de se- 
curite. Par exemple, une application peut ne com- 
muniquer qu'avec un ensemble determine de cor- 
respondants. 

• Non-repudiation : un certain nombre d 1 informations 
sur les messages echanges sont memoris6es afin 
qu'aucune des parties prenantes ne puisse renier 
le fait d'avoir participer a la communication. 

• Confidentiality : les messages sont ch iff res de sorte 
qu'un tiers ne puisse dtre en mesure d'en interpreter 
le contenu. 

[0005] Typiquement, ces services, ainsi que d'autres 
non mentionnes, sont mis en oeuvre par des applica- 
tions logicielles specifiques que i'on appelle serveurs de 
security. Plusieurs serveurs de securite peuvent exister, 
chacun fourntssant un ou plusieurs des services de se- 
curisation. De mSme chaque service de securisation 
peut etre foumi a differents niveaux de quality. 
[0006] La figure 1 presente une architecture conforme 
a l'6tat de la technique dans ce domaine. L'application 
^ souhaite securiser une communication avec ('appli- 
cation Ag. Pour cela, elle peut utifiser le serveur de se- 
curity S 1 qui fournit un support bas-niveau de cryptogra- 
phie, ou bien le serveur de security S2 qui fournit un ser- 
vice de cryptographie de haut-niveau. 



[0007] Dans le cas ou l'application A 1 utilise le serveur 
S v elle envoie dans un premier temps un message m 1 
de requete de service au serveur S v Ce serveur S 1 re- 
toume une ciy dans un message de ryponse rr^. Ensui- 
5 te, ('application A t peut envoyer son message m 3 a des- 
tination de ('application A2 apres I'avoir chiffrd avec la 
cle. 

[0008] Dans le cas ou l'application A 1 fait appel au 
serveur de security S 2 , elle confie son message a trans- 
jo mettre m^ au serveur de security S2. Ce serveur S 2 se 
charge abrs de mettre en oeuvre les techniques de 
cryptographie puis transmet le message crypty m' 2 a 
('application destinatrice Ag. 

[0009] Ces deux exemples triviaux permettent de 
J5 mettre en exergue le fait que pour un meme service de 
securisation, differents niveaux de services peuvent 
dtre disponibles. De la meme facon pour un meme ser- 
vice et un meme niveau de service, il peut exister diffe- 
rents protocol es de negociation entre l'application initia- 
20 trice (A-, ) et le serveur de security. C'est par exemple le 
cas pour la negociation de la cl6 de chiffrement dans le 
cas d'un service de cryptographie. On peut citer, a titre 
d'exemples de tels protocoles, les methodes de Dtffie- 
Hellman ou de Needham- Schroder. Ces mythodes sont 
25 par exemples presentees dans I'ouvrage intitule 'Prac- 
tical Intranet Security" de Paul Ashley et Mark Van- 
denwauver, publie aux yditions Kluwer Academic Pu- 
blishers en 1999. 

[001 0] Pour resumer, une application desirant secu ri- 
se ser une communication avec une autre application, de- 
vra §tre capable de mettre en oeuvre differents proto- 
coles de negociation en fonction du service et du niveau 
de service qu'elle desire. 

[0011] Cela implique aussi que si Ton desire rempla- 

35 cer un serveur de securite correspondant a un service 
et un niveau de service bonne, par un autre presentant 
par exemple une meilleure quality de service mais met- 
tant en oeuvre un protocole de negociation different, les 
applications devront etre modtfiees si elles n'etaient pas 

40 prevues des le depart pour ce nouveau protocole. 
[001 2] De plus, les moyens de communication a utili- 
zer pour atteindre chacun des serveurs de securite peu- 
vent dtre differents. Par exemple, chacune des applica- 
tions doit done pouvoir gerer un acces direct, ou a tra- 

45 vers un bus togiciel comme CORBA (Common Object 
Request Broker Architecture) de I'OMG (Open Manage- 
ment Group) ou DCOM (Distributed Common Object 
Management) de la soci6t6 Microsoft, ou encore a t ra- 
vers un reseau. 

50 [0013] Le but de la presente invention est, entre 
autres, de pallier ces diffyrents inconvynients. Pour ce- 
la, elle a pour objet un serveur virtue! de securite per- 
mettant a un ensemble d'applications logicielles d'acce- 
der a un ensemble de services de securite. Ce serveur 

55 virtue! de securite se caracterise en ce qu'il possede : 

• des moyens pour recevoir de la part des applica- 
tions logicielles, des requdtes de services, 
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• des moyens de communication avec des serveurs 
de mettant en oeuvre les services de sdcuritd en 
question, 

• des moyens pour choisir au moins un serveur de 
security destinataire pour chaque requdte de servi- 
ce recue et pour lui transmettre, via ces moyens de 
communication, des informations tui permettant de 
fournir le service de sdcuritd correspondant a la re- 
quete de service, certaines au moins de ces infor- 
mations dtant contenues dans la requdte de servi- 
ce. 

[0014] Selon une mise en oeuvre de I 1 invention, les 
applications togicielles peuvent accdder au serveur vir- 
tue! de s ecu rite au travers d'une interface de program- 
mat ion ou API (pour Application Programming Interface, 
en anglais). 

[0015] Selon une mise en oeuvre de ('invention, le 
serveur virtue) de security peut dtre ddveloppd en un 
langage de program mation tel Java. 
[0016] L'invention a aussi pour objet le procddd sus- 
ceptible d'etre mis en oeuvre par les applications logi- 
cielles pour utiliser ce serveur virtue! de security. Ce 
precede se caractdrise en ce qu'il comporte les dtapes 
de: 

• Emission de requdtes de service par une applica- 
tion logic ie lie a destination d'un serveur virtue! de 
sdcuritd, 

• choix, parleserveurvirtueldesecurite, d'unserveur 
de sec u rite destinataire, a meme de foumir le ser- 
vice de security correspondant a cette requdte de 
service, 

• dmission d'informations a destination du serveur de 
security destinataire afin qu'il puisse foumir le ser- 
vice de security certaines au moins de ces infor- 
mations dtant contenues dans la requete de servi- 
ce. 

[0017] La figure 1, ddja commentde, represente une 
architecture conforme a retat de fart permettant la sd- 
curisation de communications entre applications. 
[0018] La figure 2 represente une architecture gdnd- 
rale conforme a Pinvention. 

[0019] La figure 2 schdmatise un exemple d'archrtec- 
ture conforme a l'invention. Les rdfdrences A,, A2 et A3 
reprdsentent trois applications logicielles. Ces applica- 
tions peuvent dmettre trois requdtes de service, r 1 , r 2 et 
r 3 respectivement, au serveur virtuel de security V afin 
de sdcuriser les communications qu'elles ddsirent ini- 
tier. 

[0020] Selon une mise en oeuvre de ('invention, ces 
requdtes contiennent uniquement le type de services 
ddsird (confidentialitd, authentification...). 
[0021] Le serveur virtuel de security a alors pour ta- 
che de determiner le ou les serveurs de security parmi 
I'ensemble disponible S v S2 et S 3 , qui permettent de 
fournir le service demanded Pour cela, le serveur virtuel 



V peut possdder un moyen de memorisation permettant 
d'associer les services de sec u rite demandds par les 
applications et les serveurs de sec u rite fournissant ces 
services. 

s [0022] Dans I'exemple de la figure 1 , la requdte de 
service r 1 engendre une requete a, entre le serveur vir- 
tuel V et le serveur de security S 2 . Cette requdte peut 
dtre composee d'un dchange de messages entre les 
deux participants. Cet echange depend du serveur de 
sdcuritd S 2 et du protocole de negociation qu'il met en 
oeuvre. On voit que cette architecture masque le proto- 
cole de negociation en question pour ('application qui 
n'a done pas besoin de s'en preoccuper. 
[0023] Par ailleurs ('application Ag dmet au serveur 
virtuel de sec u rite V une requete de service r 2 . Cette 
requdte va dtre interprdtde par le serveur virtuel de la 
mdme facon que prdeddemment, ma is ici la realisation 
du service demandd necessrte deux serveurs de secu- 
rity, S n et S 3 , avec lesquels le serveur virtuel initio deux 
requdtes C2 et c' 2 . 

[0024] Selon I'architecture conforme a t 1 invention, les 
applications (A, , A 2 et A 3 ) peuvent n'avoir aucune infor- 
mation sur les diffdrents serveurs de sdcuritds (S v S 2 , 
S 3 ). Comme dvoqud prdeddemment, cela simplifie les 
communications entre les applications puisque celles- 
ci sont dechargdes de la gestion des diffdrents protoco- 
les de negociation, ainsi que du choix du ou des ser- 
veurs de sdcuritd approprids au service requis. II rdsulte 
de cela une simplification du ddveloppement des appli- 
cations, et done une rdduction du coOt associd. 
[0025] Par ailleurs, il est courant d'ajouter un serveur 
de sdcuritd au sein d'un systdme de gestion de rdseaux, 
ou d'en remplacer un par un autre. Dans une architec- 
ture selon I'dtat de I'art, cet ajout ou ce rem placement 
peut rdsulter sur un nouveau protocole a prendre en 
compte par les applications, ou en tout cas par un nou- 
veau serveur a prendre en compte pour remplir les ser- 
vices de sdcuritd pouvant dtre requis. Cela implique 
done necessairement (a modification de toutes les ap- 
plications concerndes. 

[0026] Au contraire, dans une architecture selon l'in- 
vention, seul le serveur virtuel doit dtre adaptd. Bien dvi- 
demment, te coOt engendrd par la modification d'un uni- 
que composant logiciel bien identifie est bien moindre 
que celui qui serait ndcessaire pour modifier tout un en- 
semble de composants logiciels hdtdrogdnes. 
[0027] De plus, I'architecture selon l'invention permet 
('utilisation de plusieurs serveurs de sdcuritd pour rdali- 
ser un meme service de sdcuritd. Cette utilisation est 
totalement transparente pour les applications. II est ain- 
si aisement possible de rendre disponibles des services 
de sdcuritd de haut niveau, et de tirer profit des capaci- 
tds des serveurs de sdcuritd pour rendre un service 
qu'its ne peuvent pas offrir individuellement. 
[0028] Par ailleurs, e'est au serveur virtuel que revient 
la charge de gdrer la localisation physique des diffdrents 
serveurs de sdcuritd ainsi que te moyen d'acces 
correspondant : accds direct ou par un bus logiciel par 
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exemple. 

[0029] En fin, les applications peuvent n'avoir aucune 
information sur les serveurs de security autres que le 
serveur virtu el V. Par consequent, elles peuvent n'avoir 
aucune information sur les protocoles de nggociation 
mis en oeuvre, et les attaques matveillantes du systems 
n'en seront que plus difficiles. 
[0030] Selon une mise en oeuvre de ('invention, les 
applications togicielles peuvent acceder aux fonctions 
du serveur virtue) au travers d'une interface de program- 
mation ou API (Application Programming Interface). 
[0031] Seton une mise en oeuvre particuliere de I'in- 
vention, le serveur virtu el de securite est developpe en 
un langage de programmation tel que Java, afin de le 
rendre ind6pendant du systeme d'exploitation sous- 
jacent. En effet, ainsi developpe, le serveur virtuel de 
security devient a mdme de fonctionner sur n'importe 
quel type de systeme d'exploitation a condition qu'une 
machine virtuelle Java soit inseree entre ce systeme 
d'exploitation et ce serveur. 



• Emission de requdtes de service par ladite ap- 
plication logicielle a destination d'un serveur 
virtuel de security, 

• choix, par ledit serveur virtuel de securite, d'un 
s serveur de security destinataire, a meme de 

fournir le service de sdcuritd correspondant a 
ladite requdte de service, 

• dmission d'informations a destination dudit ser- 
veur de security destinataire afin qu'il puisse 

10 fournir ledit service de securite, certaines au 

moins de ces informations etant contenues 
dans ladite requdte de service. 



Revendicatlons 

1 . Serveur virtuel de sdcuritd permettant a un ensem- 25 
ble duplications logicielles (A,, A2, A 3 ) d'acceder 

a un ensemble de services de securite, caractdrisd 
en ce qu'il possede : 

• des moyens pour recevoir de la part desdites 30 
applications logicielles des requdtes de servi- 
ces, 

• des moyens de communication avec des ser- 
veurs de sdcuritd (S v S 2 , S 3 ) mettant en 
oeuvre lesdits services de sdcuritd, 35 

• des moyens pour choisir au moins un serveur 
de securite destinataire pour chaque requete 
de service recue et pour lui transmettre, via les- 
dits moyens de communication, des informa- 
tions lui permettant de fournir le service de s6- 40 
curitd correspondant a ladite requete de servi- 
ce, certaines au moins de ces informations 
etant contenues dans ladite requdte de service. 

2. Systeme selon la revendication prdcddente, dans 4$ 
lequel lesdites applications logicielles peuvent ac- 
ceder audit serveur virtuel au travers d'une interface 

de programmation ou API. 

3. Systeme selon Tune des revendications precdden- so 
tes, dans lequel ledit serveur virtuel de securite est 
developpe en un langage de programmation tel Ja- 
va. 

4. Precede pour permettre a une application logicielle 55 
d'acceder a un service de securite, caractdrisd en 

ce qu'il comporte des Stapes de : 
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